A Transmission Control Protocol (TCP) session can be defined as “A logical end-to-end data communication link between two applications, using TCP as protocol”. Regular TCP restricts communication to a single path per session. Internet Engineering Task Force (IETF) is currently developing mechanisms to add a capability of simultaneously using multiple paths in a regular TCP session. The extensions to TCP, called “multi-path TCP” (MPTCP) are described in Internet-Draft “http://tools.ietf.org/html/rfc6824”. Architectural guidelines for multipath TCP development have been published in RFC 6182. RFC 6182 defines a “path” as a “sequence of links between a sender and a receiver, defined in this context by a source and destination address pair”.
In many cases multiple paths exist between peers. An example of this is the case where one or both of the end-devices are multi-homed and/or have connectivity via more than one access technology. For example, in a 3rd Generation Partnership Project (3GPP) multi-access scenario, a User Equipment (UE) device may be connected via both a 3GPP access (such as GSM EDGE Radio Access Network, GERAN, Universal Terrestrial Radio Access Network UTRAN, Evolved Universal Terrestrial Radio Access Network E-UTRAN etc.) and a Wireless Local Area Network (WLAN) access simultaneously. The simultaneous use of these multiple paths for a TCP session would improve resource usage within the network, and improve user experience through higher throughput and improved resilience to network failure. The use of MPTCP over multiple accesses would allow the user traffic to be either routed only over one of the accesses or simultaneously over multiple accesses. It would also allow the traffic to be moved in a seamless fashion between accesses depending on coverage, radio link quality or other factors.
In regular TCP, one TCP session between two hosts corresponds to one TCP flow between those hosts, carried over a single path. Referring to FIG. 1 herein, in MPTCP, one TCP session between two hosts 1, 2 corresponds to one or more MPTCP subflows between those hosts, each carried over a path. A subflow is defined by a 5-tuple (source address, source port, destination address, destination port, protocol).
The model illustrated in FIG. 1 requires that both hosts are MPTCP-capable. In practice, when MCTCP is introduced to networks it is likely to be introduced in an incremental way. There is therefore a high probability that only one host will support MPTCP. To overcome this problem, it has been suggested that an MPTCP proxy 3 may be used, as illustrated in FIG. 2. One use case may be that the MPTCP proxy is placed in the network of an operator, and that the MPTCP-capable host is a UE controlled by the operator.
Host B, shown in FIG. 2, is not MPTCP-capable. A single TCP session between Host A 1 and Host B 2 corresponds to one or more MPTCP subflows between Host A 1 and a proxy node 3, and to a single TCP flow between the proxy node 3 and Host B 2. The proxy node 3 multiplexes the MPTCP subflows towards Host B 2 into a single TCP flow, and demultiplexes the single flow towards Host A 1 into subflows.
RFC 6182 defines a regular/single-Path TCP as the standard version of TCP in use, operating between a single pair of addresses and ports. Multipath TCP is defined as a modified version of the TCP protocol that supports the simultaneous use of multiple paths between hosts. A path is defined as a sequence of links between a sender and a receiver, defined in this context by a source and destination address pair. A Host is defined as an end host either initiating or terminating a Multipath TCP connection. A subflow is defined as a flow of TCP segments operating over an individual path, which forms part of a larger Multipath TCP connection. A MPTCP connection is defined as a set of one or more subflows combined to provide a single Multipath TCP service to an application at a host. RFC 6182 also notes that MPTCP makes use of (what appear to the network to be) standard TCP sessions, termed “subflows”, to provide the underlying transport per path, and as such these retain the network compatibility desired. MPTCP-specific information is carried in a TCP-compatible manner, although this mechanism is separate from the actual information being transferred.